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ABSTRACT 


A study of errors occurring in stored data structures 
is made here. We restrict ourselves to structural errors. 
Structural errors are those changes which modify one or more 
nondata fields of nodes in a data structure instance. An 
axiomatic model for an implementation of a data structure is 
proposed for analysing its error detection capabilities. 

Some commonly used data structures are analysed using this 
model. A systematic method is suggested for deriving 
detection and diagnosis procedures for structural errors from 
the axiomatic descriptions. The problem of synthesis of data 
structures with a view to increase robustness is also dealt 
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1. INTRODUCTION 


1 • 1 Overview of the problem •, 

Software reliability presupposes the reliability of 
stored data structures upon which the programs operate. 
However, the stored data is prone to hardware and software 
errors. Redundancy is the key to robustness of data. Some 
portions of the data could be classified as the semantics or 
'real data’ while others are used to indicate the relationship 
between the various items in the data, classified as the 
structural information. In this study, we concentrate only 
on structural redundancy, which might be present for 
reasons other than reliability too. The semantics, is to be 
protected by using proper error detection/correction codes 
for storing the data. 

1.2 What is a structural error? 

The nondata or structural fields in a data structure 
are included to enable and simplify access to nodes and to 
speed up processing involved in performing standard opera- 
tions (include, delete, read etc.) on the data structure. 

Some typical instances of structural fields are pointer, 
count, structure identifier, index limits etc. 
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A structural error in a data structure is any 
unintentional change in the structural fields of the data. 
This causes a valid data ' structure instance to change 
to either a valid or an invalid instance. Typical examples 
of structural errors are ’lost pointers' (pointers going 
astray) and a change of an identifier field associated 
with a node or a stored count. 

1.3 Sources of errors i 

The model we will use concerns itself only with the 
errors (i.e., the effects of failures) and not with the 
sources of error. However, it is only with reference to the 
actual failures causing errors that the validity of the 
assumption made in the model can be justified. 

The errors could be due to one or more of the following 
reasons : 

- Hardware errors (in the processor or in the storage 
and transmission media) 

- Errors in user access to data 

- Original creation of the data structure itself 

can bo wrong, duo to some bugs in the- creating program 

- Abrupt stoppage of update routines (As in the case 
of a system crash). 
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1.4 Measures of Robustness : 

We will be concerned only with the robustness of 
structural information. Commonly used measures of robustness 
are detectability and correctability. Detectability is the 
maximum number of structural errors that can be detected. 

In effect, it signifies the maximum number of changes in 
structural data that will not lead to a valid instance of 
the data structure. Correctability denotes the maximum 
number of detectable structural errors that can be 
corrected to yield a unique valid instance. Other measures 
also exist and a summary of these can be found in [ l] . 

1.5 Survey of the work already done ; 

The need for reliable data has long been realised. 

As early as 1968, Lockemann and Knutsen [5] proposed a method 
for recovery of disk contents after a system crash. It was 
basically an introduction to the idea of adding an unique 
identifier field to each record, which was later used 
extensively by Taylor et al. [ l] , [6-8]. Error recovery 
using ,log files, audit files, or using before- and after- 
images are standard ways of guarding against errors in data 
bases [3]. Only those parts of the data which wore accessed 
during certain interval of time arc duplicated in the form 
of log files, transaction files or before— images. This 
method, therefore, constitutes limited duplication of data 
and will not guard against all possible errors. 
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The idea of adding structural redundancy in terms of 
additional pointers is of obscure origin. The standard 
doubly linked list has come to stay, though their extensive 
use was made first in some of the implementations of the. 
list processing languages. Even then, additional fields 
were added, not as a means of redundancy, but as aids to 
operations on the data structures. Likewise, the addition 
of a count of the number of nodes is also an advantage at 
very little extra cost and has been used for long. 

An analysis of the error detection and correction 
capabilities of data structures for structural errors was 
first carried out by Taylor, Morgan and Black [6]. Some 
novel storage structures with improved roubustness are 
suggested in [6], and some of the experimental results about 
the robustness of data structures are also provided therein. 
The performance measures are presented in [l]. The theoretic 
aspects of the error detection/ correction capabilities of 
data structures in general are dealt with in [7], Some 
detection procedures are also given in [6]. Correction 
algor ithrns for some of the standard structures, as also the 
principles underlying their development, are given in [8], 

1.6 Purpose of current study ; 

A rigorous mathematical analysis about the detectability 
of data structures is contemplated. So far, no attempt has 
been made in this direction. The reason was, apparently, the 
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lack of a proper model of data structures, except a graph 
m oddL by Harley [2], Therefore, a mathematical model for 
data structures is also proposed. Apart from this, the need 
for a systematic method of developing detection procedures 
. for any arbitrary data structure was felt and an attempt is 
made in Section 4 towards this. Diagnosis and correction 
algorithms can also bo developed likewise for some of the 
cases. Finally, the problem of designing robustness in 
storage structures is considered in Section 5, after 
introducing the redundancy functional to characterize the 
redundancies in a data structure. 



2. A MODEL FOR DATA STRUCTURES 


2. 1 The need for a model i 

We propose to do a rigorous analysis of data structures 
in terms of its error detecting capabilities. A mathematical 
model will be appropriate for this purpose. Let us consider 
what are the features of a data structure which the model 
should capture. 

The model need not tell anything about the user opera- 
tions on the data structure. We are only concerned with the 
consistency of representation at any instance of time, 
independent of how it was arrived at. So, the user opera- 
tions on the data structures are of no concern to us. But 
the model has to bring out those features which characterise 
a particular implementation of data structure. 

For example, a binary tree could be implemented either 
as linked structure (with LSON-RSON fields) or as a linear 
array. Though the difference in implementations is supposed 
to be transparent to the user, wo expect that our model 
should preserve this difference, as the robustness depends 
very much on the implementation. 

Thus, in effect, when we say a data structure, we also 
mean a particular way of implementing it, and the model 
should be able to differentiate not only among various data 
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structures, but also among a variety of implementations of 
one data structure. 

2. 2 The Abstract Mathematical Model % 

A structure is denoted by S, its nodes by ... etc. 

Normally, there is a distinguished node Mj in S, called the 
header of the structure. In some cases, there may be more 
than one header, N^, add all the headers are linked 

together. Each of the headers is individually accessible 
without having the need to chase 'pointers. 

Fields are associated with each node* The fields 
could bo 'data fields' or ’structure fields’. Here, we 
concentrate only on structural fields. The fields associated 
with a node are denoted by f ^(N^) , f ^(N^) etc. It should 
be noted that f^(N^) is only a shorthand notation for the 
field of and should not bo looked upon as a function with 
argument as such. 

Mil is a standard value which can be associated with any 
link typo field and no field can be associated with it. For 
convenience, we will use the following notations i 

(where k^o) indicates chasing the ’ f^’ field k times 

(where k<To) indicates that node from which the 
current node would be reached after chasing ’f^ 1 field 
k times. 
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Every data structure is represented by a set of 
axioms or assertions. The assertions represent only the 
static nature of the data structure and no mention is made 
about the user operations on the data structure. 

2. 3 Representation of some common data structures ; 

We now give examples of representing some of the 
standard data structures in terms of the above model. 

2.3.1 SINGLY LINKED LIST ( SLL ) 

Consider a non-redundant implementation of SLL which 
has a pointer field f^ (Fig. 2.1). It is uniquely chara- 
cterised by the following assertions s 

Assertion 1 : (a) e S and f^(N^) = N 2 =^N 2 £ S 

(b) T n £ S * ^l(N^) = N 2 for some finite 

k >/ 0 

The above assertions say that any node pointed to by 
another node belonging to the structure is also in the 
structure. Assertion l(b) states that the list is circular. 

2.3.2 Robust SINGLY LINKED LIST (r-SSLL) $ 

Suppose the above representation of a simple singly 
linked list (SLL) is extended by introducing an Identifier 
field (1^) with each node. In addition, let us assume that 
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the header node has a ’count field’ indicating the number 
of nodes in the structure (Fig. 2.2)* We shall call this 
structure as robust SINGLY LINKED LIST (r-SLL ) . (It is 
possible that the header node might have a different 
node structure than the rest of the nodes). 

This structure is characterised by the following 
assertions i 


Assertion 1 : 


(a) e S and f^(N^) = ^ N 2 e S 

(b) ¥- Nl ,N 2 e S, f^(N 1 )=N 2 for some 

finite k ^ o. This assertion says just 
those properties of r-SLL which are shared 


by SLL. 

Assertion 2 : f^l^) = N 2 I^t^) = I d (N 2 ) 

This is to say that if two nodes are 
’connected' they have the same 1^ value. 
Together with 1(a), this also implies 
that all the nodes in the structure have a 
unique Identifier value. 

Assertion 3 i If m = count (S) 

then f^(N H ) = Nj_r if* k = m+1 

(for circular lists) 
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If m is the stored count of the number of nodes in 
the structure, then, starting from the header, we must 
reach back to the header, after following the f^ field 
successively m+1 times. This should not happen for 
any othor sequence of following the pointer field. 

The significant fact here is that m is a known 
constant. 

2.3.3 DOUBLY LINKED LIST (DLL) : 

Now assume that, on the structure of a r-SLL, we make 
the following modification. Every node has an additional 
pointer field f 2 and it points to the predecessor of the 
node, (if we consider f^ field to contain a value that 
defines the normal sequence of nodes). See Fig. 2.3. 

This structure will be called the doubly linked list 
(DLL) and is characterised by the following assertions : 

Assertion 1 : (a) N^ e S and f^(N^) = e S 

(b) V N lf N 2 £ S, f* (N x ) =* N 2 

for some finite k ^ o 

Assertion 2 : (a) f^CN^) m 

(b) f 2 {U ± ) * N 2 = ^f 1 (N 2 ) = N x 

These just mention the fact that if node N^ points 
to N 2 in the forward sequence (via f^) , then N 2 points to 
(via f 2 ) t and vice versa. 
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Assertion 3 % (a) = N 2 ^ I d (N 1 ) = I d (N 2 ) 

(b) f 2 (N 1 ) = N 2 ^7 > I d (N 1 ) = I d (N 2 ) 

Assertion 4 s If m = count (s) 

then (a) if:, k = m+1 

(b) f 2 (N H ) = N h if: k = m+1 

Assertions 3 and 4 are direct extensions of the 
corresponding assertions for r-SLL. 

2.3.4 MODIFIED (2) DOUBLY LINKED LIST : 

This is a novel doubly linked list suggested in [6] . 
Here, instead of the back pointer (content of f 2 field) 
pointing to the previous node, we make it point to the node 

preceding it. This will be referred to as the mod (2) DLL. 
The number 2 indicating the distance spanned by the back 
pointer (Fig. 2.4). Note that there are two headers and 
N H2 . In general, it will be required to have k headers 
for a mod (k) DLL. 

This structure is uniquely characterised by the 
following assertions i 

Assertion 1 i (a) z S and f^O^) - e ® 

(b)'» e S, f^O'^) = N 2 for some 

finite k ^ o 

This is same as for the DLL. 
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Assertion 2 s (a) f^O^) = M 2 ~>f 2 ^ N 2^ = N i 

(b) f 2 (N 1 ) = N 3 ^f^(N 3 ) = N 1 

This brings out the essential difference between a DLL 
and the mod (2) DLL. 

Assertion 3 : (a) f^(N^) = N 2 =>I d (N 1 ) = I d (N 2 ) 

(b) f 2 (N 1 ) = N 2 ^ X d (N 1 ) - X d (N 2 ) 

This is again same as for the DLL. 

Assertion 4s If m = count (s) 


then 

(a) f^(N H1 ) = N H1 iff k = ra+2 

<b) ^ 


and f 2 (MH 2 ) 


iff 



+ 1 for m even 

m+2 for m odd 


Assertion 4(b) is a consequence of having two headers 
and it is necessary to consider the casesof even and odd 
values of the number of nodes separately. 

2. 3'. 5 SIMPLE BINARY TREE : 

We consider the standard binary tree implementation with 
Left link and Right link fields (f^ and f 2 respectively) to 
denote the left and right son. 
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It is characterised by the following assertions : 

Assertion 1 : „ „, rt , 

' N1 e S, N2 ^ nil 

(a) f 1 (N 1 ) = N 2 c^N 2 e S 

(b) f 2 (N 1 ) - e S 

This asserts that a node could be ’connected' to its 
parent either through the left or the right field. 

Assertion 2 : (a) %(%) = l^^f^N) k n 2 and f 2 (N) £ N 2 

for any N /= 

(b) f^N^ = N 2 (N) /= N 2 and f 2 (N) £ N 2 

for any N /= N i 


(c) f 1 (N) /= 

f 2 (N) £ % 


for any N e S 


This asserts the acyclic property* 

2.3.6 THREADED/ CHAINED BINARY TREE S 

The left and right link-fields of those nodes which 


contain logically null value do not contain much information. 
These fields, therefore, could be used to represent some 
other relationship among the nodes. The null right fields 
might be 'threaded* to point to its in-order successor and 
the null left fields can be 'chained' to the next such 


node in the in-order sequence whose left field also contains 
a logical nil value, as suggested in [7], Tags t^ and t 2 
might be npeded in this case to indicate whether the fields 
f^ and f 2 contain normal pointers or not. Tag = 0 may indicate 
a normal pointer. Refer Fig. 2.5. 
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The assertions characterising .this structure follow : 
Assertion 1 : Y* N1 e Sf ^ £ nil 

(a) f 1 (N 1 ) = N 2 H 2 e S 

(b) f 2 (N 1 ) = N 2 e S 

This is identical to the previous case. 

Assertion 2 : 

(a) V N1,N2,N e S (N 2 h %) 

( t^(Ni) = 0 and f i (N 1 ) = N 2 ) 
or (t 2 (N 1 ) = 0 and f 2 (Nl) = N 2 ) 
f^(N) N 2 for any N j=- s.t. t-^(N) ~ 0 
and f 2 (N) N 2 for any N s.t.t 2 (M) = 0 

(b) f^(N) Nj_j for any N e S. s.t.t^(N) — 0 
and f 2 (N) ^ N H for any N e S s.t.t 2 (N) = 0 

This assertion just states that the 'normal pointers' 
do not form a cycle. 

When the tag — 1* indicating that the associated field 
contains a thread or chain* we can look upon those fields to 
contain a value dictated by a functional associated with that 
field. These are single valued functionals on the nodes of 
the structure. Some typical examples of the functionals are : 
FI The Inorder successor function 

F2 The function which gives the next node N 2 in the 

inorder enumeration sequence such that tag(N 2 )= 1. 
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This is stated in the following assertion. 


Assertion 3 i (a)V~, 


N e S such that = 1 


W ■ W 


(b) ¥k 


N e S such ^2^1^ = 1 

f 2 ( Nl ) - 6,0V 

When the examples of and F^ given shove are fitted 
in the assertion, the structure becomes a chained and threaded 
binary tree. 

Assertion 4 s (a) f^(N^) = ^2 := 7 ? *d^l^ = ^d^2^ 

(b) f 2 (N 1 ) = N 2 ^’I d (N 1 ) = I d (N 2 ) 


This assertion assumes an identifier field to be 
associated with every node and containing a unique value 
throughout the structure. 

2.4 The error model 

The types of errors which we consider for the purpose 
of this study, as also the assumptions made therein are 
presented below. 

2.4.1 Assumptions s The Valid State Hypothesis 

The basic assumption which we make in the model, which 
will also be carried over throughout the analysis is what is 
called the ’Valid State Hypothesis [7]. The hypothesis 
can be stated as under i 
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- Links outside a particular instance do not point 
to any nodo within the instance, and 

- The unique identifier value of an instance, whenever 
used, appears only in its own identifier fields. < 

Thus, no node in the 'garbage 1 either contains a pointer 
to any node in the structure under consideration or contains 
an I^-field that is unique to the structure. 

The Valid State Hypothesis seems a little unrealistic 
at the first sight, as it demands something about the 
'garbage' and other structure instances also. But once the 
Valid State Hypothesis is maintained true in a system, then 
it could continue to be maintained if all deletions of nodes 
(whenever they are released to the garbage) are accompanied by 
the process of making the pointer fields of deleted nodes 
nil and changing the 1^-field content to a value that is 
unique to the nodes in the garbage. This ensures the validity 
of the hypothesis. All da ta~ac cessing programs are supposed 
to abide by these norms. 

2.4.2 The Errors 

We allow an arbitrary .change of any arbitrary field(s) 
of arbitrary node(s). Any hardware error or software error 
could be modelled as above. Unless otherwise stated, the 
analysis and synthesis would pertain to errors occurring not 
only in pointer fields but also in the Id-fields and count, 
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wherever present. Vie, however, preclude errors occurring 
in the 'data fields' as our subject matter concerns only 
errors in structural information in a data structure. Multi- 
ple errors are unintentional changes in more than one 
field of a single node or in identical or different fields 
of different nodes. 

An error in terms of the abstract mathematical model 
would be violation of one or more of the assertions des- 
cribing that structure. 

Also, it is possible, that an assertion could be 
violated by more than one type of error. 

A note about the class of faults called 'Macro 
faults' by Black et al. [ l] would be in order. These faults 
are those in which all the structural information contained 
in a node are lost and can be thought of as an arbitrary 
number of multiple faults (in fact, as many errors as there 
are fields in the node) occurring in that node. This class, 
therefore, is not separately ’treated. 
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3.' DETECTABILITY 

In this section, formal proofs about the detectability 
of some standard data structures are given in the light of 
the model proposed in Section 2. Each such proof is 
accompanied by an informal argument about the detectability. 
Most of the proofs are not just proofs of detectability 
but also tell which assertions are violated by which types 

of faults. 

The analysis assumes the error model mentioned in 
Section 2. Only structural errors, like errors in stored 
count. Id-field and pointer fields, are therefore consi- 
dered. 

Consequently, for linked data structures, the errors 
could be classified into one or more of the following s 

1) Error in Pointer fields 

2) Error in stored count, if a stored count exists 

3) Error in Id-field, if an Id-field exists. 

Error is caused by unintentional change of any of the 
above mentioned fields. 

In the following subsections a reference to assertion 1 
etc. would refer to the Indicated assertion for that type 
of data structure, as found in Section 2. 
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3.1 SLL ; 

A singly linked linear list with no redundancy has 
only one assertion, so no redundancy exists. We note here, 
that any additional assertion amounts to redundancy, as 
just assertion 1 is sufficient to access all the nodes of a 
linearly linked list. 

Let the error occur in node Nj_ belonging to S. 

Let f^(N^) = N 2 previously before the change and let it 
change to Now, by assertion 1 , Ng e S. 

There is no way to find out whether the change was inten- 
tional or an error. 

Hence the dc-tactability is zero. 

3.2 Robust-SINGLY LINKED LIST (r-SLL) i 

(This structure has an Id-field in each of the nodes 
in addition to a stored count of the number of nodes in it). 

(a) Change in Id-field ; 

Let N 2 e 3 and Id(N 2 ) be in error. 

Then, s 3, s.t. f'^(N^) = N 2 

(This follows from assertion l) 

But assertion 2(a) states that 

Id(N 1 ) = Ib(N 2 ) 

An invalidity is reached here in assertion 2(a). 
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( b) Change In stored count s 

Let the old count be m and the new value, after error, 
be n(?£ m.) . 

(There Is no other change, since we are now concentrating 
only on single errors). 

Jr 

Initially (Hj) = only for k = m+1. 

Hence, (N H ) = i^. 

Also, f^ + ^ = Npr, after the change. 

Since n is different from m, n+1 4 m+1. 

Therefore, assertion (3) is violated. 

(c) Pointer field change i 

Let the pointer field of change. 

Initially, let f^(N^) = N£, later f^CN^) = 

If Id{N 3 ) ^ Id(N 1 ) , then is a ’foreign' node and 
assertion 2(a) is violated. 

If Jd(NL) = Id(N ) , then, under the assumption that 
o X 

there is only a single change, N 3 belonged to the structure 
S previously too. 

k i 

Let f^ 1 (Npj) = 
k o 

f 1 z (N 3 ) = 1%, for some k^k^ y>, o 

Also, we know that, f^O^) = N 3 » 
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k +k 0 +l 

He- nee, ^ (N H ) = N H 

So, k^+k^ = m, if assertion (3) were valid* 
There are now 2 cases s 
Case 1 ; k 2 <C. rn.-k^ 



Fig. 3.1 Illustrating case (l) of the proof 
m=7 , k =2, k 2 =4 (k^^Cm-k^) 

In this case, 

k^+k^ = m ^ k 1 +m-k 1 m or m<^m 

A contradiction is reached here. Hence, assertion (3) 
could not be true in this case, and is the one that is 
violated. 

Case 2 s k 0 rn-k+1 

(In this case, k.+k 2 = m m+1 ^>. m which is not much 
information). 

k 

Observe that (N^) = 

f i°V = n 3 

f 1 "(N 3 ) = % 

k 0 ~^y*/ m+1— k . . 


wi th 
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It, then, follows that 

m , m+k.+l 

f^(K H ) =-N h f x 4 (%) = N h 

The uniqueness of ’ k ' in assertion (3) is lost and so 
assertion (3) is violated. 

Informal Arguments ; 

Assertions (2) and (3) are redundant as far as access 
of nodes are concerned. Together, they add to the detecting 
capability of the structure. It should be noted that, every 
'redundant* assertion might not increase the detectability 
by one. As in this case, assertions (2) and (3) cater for 
different types of errors, and, together ’cover' all the 
errors, so, together, they increase the detectability by one. 
Assertion (2) helps in detecting a pointer change to a foreign 
node and assertion (3) will help in detecting some nodes 
getting deleted by a single pointer change. 

We can summarise the above discussion by recapitulating 
the results. Mentioned below are the detecting capabilities 
of various assertions i 

1) Id-field change s Assertion 2a detects 

(No other procedure Is able to detect) 

2) Count change ■ s Assertion 3 detects 

3) Pointer field change ; 

a) To a foreign node s Both assertions 2a and 3 detect 

b) To a local node s Only assertion 3 detects 



27 


3.3 DOUBLY LINKED LIST (DLL) i 

The types of errors here are s 

1) Error in Forward pointer (f^field) 

2) Error in back pointer (f 2 ~field) 

3) Error in stored count (m) 

4) Error in Id-field (Id-field) 

Any single error is ’detected’ by violation of 
identical assertions as in the robust singly linked list 
(r-SLL) case. 

In addition, the errors of type (l) and (2) are also 
detected by violation of assertion 2. 

Any double error, not involving both pointer fields f^ 
and f^y is also detected likewise and we will not go into 
its details. 

The only interesting case is when both the pointer fields, 
f^ and f 2 » of two nodes change. 

Let = «2 Chang 0 to f^l^) = Ng. 

If the f 2 field of Ng does not change, then this error is 
detected by violation of assertion 2* 

So, assume f 2 (W 3 ) = N 4 , changes to f 2 (N 3 ) = N 1 * ’ 

Assertion (2) is now held valid, but assertion (4) is found to 
be violated, as in the case of robust singly linked lists. 

If Ng is a foreign node, then assertion 3 itself is violated. 
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thus, all double errors are detected and so, the 
detectability is two . 

An instance of 3 errors that goes undetected is a pair 
of pointer changes involving f ^ and fields together with 
a change in stored count. Informally, apart from the 
detection capability of r-SLL, the DLL has got an additional 
detectability because of assertion 2. Hence, the detecta-^"* 
bility is one more than that of r-SLL. Recapitulating, we 
can present the results of the above discussion by listing 
out which types of errors are detected by what assertions. 

1. Id-field change ; Assertions 3a and 3b detect 

2. Count change s Assertions 4a and 4b detect 

3. Forward pointer (f^-field) change s 

a) To a Foreign node i Assertions 2a,2b,3a and 4a detect 

b) To local node i Assertions 2a, 2b and 4a detect 

4. Back pointer (f 2 -field) change i 

a) To a foreign node : Assertions 2a, 2b, 3b and 4b detect 

b) To a local node ; Assertions 2a, 2b and 4b detect.. 

These results will be used later in Section 4 to construct 


the ’Syndrome Table' 
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4. DETECTION AND RECOVERY PROCEDURES 

Given a data structure described in terms of a set of 
assertions to be satisfied, a semi-automatic method of coming 
up with detection procedures for structural errors is now 
presented. 

4.1 Procedural Specifications of Data Structures i 

Each of the assertions Is converted to an algorithm or 
procedure which checks for the validity of the assertion. 
Each of the procedures will return a true/false value for the 
error flag associated with it. Any instance of the structure 
is made to pass through the procedures which are algorithmic 
equivalents of the assertions describing that data structure. 
A success or failure is indicated in each case by the value 
of the error flag. A success would mean no detected error 
and the corresponding error flag will be returned as false. 

Note that many types of errors could be detected by a 
single procedure. Some of the procedures return a suspected 
node, whose field is to be modified when correction is 
attempted. 

In converting an assertion to a procedure, it may be 
necessary to do the following changes, which are not present 


in the assertions i 
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i) Some procedures also return a suspect node, as noted 
above, though the assertions do not say anything 
about it. 

ii) To terminate the algorithm, in particular, to avoid 
indefinite looping in some cases, some modifications 
might be needed. 

The failure or success of each procedure is calculated 
and the aggregate of these results is used to detect as 
well as pinpoint the type (and possibly, the location) of 
error that has actually occurred. 

A general method of doing so is indicated below. 

4. 2 The Syndrome Table ; 

The identification of the various types of possible 
errors that can occur in the data structure is a key step in 
what follows. In case of multiple errors, all combinations 
of single error types are to be considered as possible. 

Having identified the various types of errors, an 
analysis of the data structure in the light of the asse- ns 
describing it is to be carried out on the lines of Section 3. 
It will bo able to tell which procedures return a true value 
for which type of faults (errors). This information, when 
presented in a tabular form is called the syndrome table. 
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The syndrome table for a robust singly linked linear 
list (r-SLL) with a stored count and Id-field is given below. 

Error flags 


't' 




Error flag 

3 

No error 

F 

F 


Id- field change 

T 

F 


Count change 

F 

T 


FP(f 1 ) to foreign 

1 node 

T 

T 


FP to local node 

- 1 

F 

T 

U- 

Jl 


Fig. 4.1 The syndrome table for SLL 

The entries in the table show the values of the corres- 
ponding error flags upon exit from that procedure. 

The syndrome table is a master table which will be used 
not only to detect errors but also to pinpoint the type of 
error and, coupled with the suspected node values, to 
locate the error in some cases. This aspect is important to 
correction. We are not only able to detect, but also diagnose 
the errors. 

A row in the table is a ’syndrome' for that particular 
type of error. Any actual syndrome (a soguence of test 
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results) obtained as a result of passing the instance of 
data structure through the various procedures is compared 
with the table to identify the type of error that could have 
lod to the syndrome. 

A note about the utility of the syndrome table will be 
in order. A particular syndrome table will be able to 
diagnose an error to be of a particular type only if the 
syndrome for that type is unique in the entire table. 
Otherwise, the resolution will be affected and it will only 
be possible to identify the actual error to be one among a 
set of types of errors and additional chocks (perhaps, 
involving the suspect-node values) may be necessary to 
resolve further. 

The procedures for detection for some of the standard 
data structures can be derived, and are presented by way of 
examples, along with the syndrome tables. The results of 
the analysis, given in Section 3, are utilised to construct 
the syndrome tables in each of the cases. 

4. 3 The robust singly linked list (r-SLL) s 

We consider here, the robust singly linked list with a 
stored count and having an Id-field In each node. Its 
detectability is one. 
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4.3*1 Procedural specifications j 

There are two 'redundant 1 assertions in the specifi- 
cation of an r-SLL (Section 2, page 11 ). Those are 
assertions 2 and 3. Given below are their procedure equi- 
valents. 

Assertion 2 % 

The procedure given below checks for the validity of 
assertion 2 of r-SLL over the entire node space of a given 
instance of data structure. The procedure checks for the 
assertion in a loop, each time checking for a different 
node. Termination of the procedure in a finite time is 
ensured by including the presence of an -detected error or 
the number of nodes encountered so far exceeding the 
stored count as a termination condition for the loop. 

Procedure 2 (NH : Node)* 

•^checks for the validity of assertion 2 of r-SLL^ 

Global Var Error 2: Boolean* 

Suspect 1, Suspect 2; Node* 

Var Nod0} 

m, nodecounts Integer* 

Bogin 

Nls= Njj# Error 2 s= false* Suspect 1; = nil* 

Suspect 2j = nil* 


contd 


• • * 
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^ Begin 

N1i=Nh» Error 2 s=false$ Suspect ls=nilj 

Suspect 2s=nilj | 
nodecounts = 0, ms=count (N^) * 
repeat 

N2s—f^(N^) jNodecounts =nodecount +1} 

If ( Id(Nl) = Id(N 2 )) 
then Nls=N2 
else Error 2s= True 

until (N2=N^) or (error 2) or (nodecount m+l) 

If error 2 

then begin 

Suspect is = N. 

Suspect 2s = N 2 
end 

end* 

Assertion 3 s 

The procedure given below checks for the validity of the 
assertion 3 of the specifications of r-SLL given in Section 2 
(page 11) over all the nodes in an instance. It checks if 
the stored count matches with the counted number of nodes when 
a traversal is made. 
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Procedure 3 (N^ % Node).) 

^checks for validity of assertion 3 of r-SLLjf 
Global Var Error 3; Boolean? 

Var N1,N2: Node? m, nodecounts Integer, 

Begin 

Nl:=NH? K i =0? Error 3:=false? ms=count(N H ) ? 
repeat 

N2s=f 1 (Nl) > k:=k+l? 

If (N2=NH) 

then error 3:= k ^ m+1 
until (k = ra+l) or (error 3)? 

If (k = m+l) then error 3s=N2 ^ NH 
end? 

4.3.2 The syndrome table for r-SLL (single errors) : 

There are basically three types of errors : 

1) Id-field change (Id) 

2) Count change (m) 

3) Forward pointer change (f^) 

The last can be further split up into two s 

a) Forward pointer changing to a 'foreign' node 

b) Forward pointer changing to a 'local' node 

These are exactly the same types of errors that wore 
considered in Section 3 for analysis purposes. Use is made 
of the summarised results presented in Section 3 (page 26). 
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Only point to note is that if an assertion is used to 
detect a particular type of error, the assertion is 
going to return a true value for the error flag associated 
with that assertion. For example, since an Id-field change 
is 'detected 1 by assertion 2, we can say that, in the 

presence of this error, erroiSLwill bo true and error 3 will 
be false. 

The syndrome table, therefore, looks as shown in 
Fig. 4.1. 

4.3.3 Comments i 

It is observed from the syndrome table that any 
erroneous instance produces a syndrome that is different 
from the one for the correct one, so detection is guaranteed. 
Since two of the rows are identical, it is not possible to 
differentiate between a change in stored count a^nd a pointer 
changing to a node in the same instance. This is expected, 
as it is an inherent property of the r-SLL that its 
correctability is zero. But, it can also be observed that 
not all single errors can be diagnosed, though in some cases, 
it is possible. (Diagnosis would mean finding tho typo of 
error and tho location where it has occurred). 

4.4 The Doubly Linked list (DLL) : 

The doubly linked list, whoso assertions are given in 
Section 2 (page 12) has a detectability of two. Construction 
and comments about its syndrome table follow. 
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4.4.1 Procedural specification ; 

The procedural equivalents of the assertions that 
specify a DLL are given in Appendix 3. 

4.4.2 The syndrome table for DLL (The single error) : 

The following typos of faults are identified s 

1) Change in Id-field (Id) 

2) Change in stored count (m) 

3) Change in forward pointer (f^) 

4) Change in back pointer 

Again, the types of faults (3) and (4) can be subdivided 
into the following classes i 

a) The pointer changing to a ’foreign* node 

b) The pointer changing to a ’local’ node. 

When only one of the above types of faults is assumed to bo 
present, it is a case of single errors in a doubly linked 
list. Here, it can be observed that the errortype resolution 
(diagnosis) is perfect in case of single errors, a prerequisite 
for correction, as expected. 

The above are exactly the types of errors considered in 
Section 3 for the analysis of DLL (page 27). The summary 
of the results presented therein is used to construct the 

syndrome table. 

The syndrome table, therefore, is as shown in Fig. 4.2. 
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Error flags 


« 


Error 

2b 

Error 

3a 

Error 

3b 

Error 

4a 

Error 

4b 

Mo error 

F 

F 

F 

F 

F 

F 

Id- field change 

F 

F 

T 

T 

F 

F 

Count change 

F 

F 

F 

F 

m 

Hi 

f 1 change to 

1 foreign node 

T 

T 

T 

F 

T 

F 

f 1 change to local’ 

1 node 

m 

t ; 

' F 

F 

- ! 

T 

F 

. change to foreign 

1: node 

T 

; 

T 

F 

■ T 

F 

T 

i'f^ change to local 
node 

. T 

T 

F 

F 

, F 

T 

! ; . 

; 

• 








(Fig. 4.2 The syndrome table for DLL) 


4.4.3 Comments ; 

Since the correct instance results in a syndrome that 
is different from the syndromes for any of the erroneous 
instances, detectability is guaranteed for single errors. 
Also, since no two rows are identical, the diagnosis is 
perfect : given a syndrome arising out of a sot of tests, 
we can pinpoint the type of error. Then, in conjunction 
with the knowledge about the suspect-nodes, the location 
of the error can also be identified. 
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In fact, some of the test procedures like 4a and 4b 
could be avoided if use is made of the suspect-nodes 
returned by other procedures in diagnosis* For example, in 
the absence of procedures 4a and 4b, it appears from the 
syndrome table that a forward pointer change to a local 
node is indistinguishable from a back pointer change to 
a local node. However, this can be resolved by looking at 
the suspects returned by each procedure. The method is 
indicated in Appendix 1. 

4. 5 The sequence of application of test procedures i 

Though the procedures testing the validity of the 
assertions are given independent of each other, and can be 
used as such, it may be more efficient to apply them in a 
predetermined sequence. 

Some of the types of errors are uniquely identified 
even by a few of the test results (a subsyndrome) and in such 
cases, it is not necessary to find out the full syndrome. 

Those test procedures which suffice to uniquely identify 
a syndrome belonging to the syndrome tabic are to be applied 
prior to the application of other test procedures to avoid 
application of unnecessary procedures. 

An example, in case of DLL is to first apply 2a and then 
3a so that an Id- field change, if present, is detected without 
the application of other redundant procedures (Hence, on this 
count, a good sequence will first apply procedures 2a and 3a 
before other procedures). 
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Another reason why not all the test procedures need 
to be applied is exemplified by the correction algorithm 
for a doubly linked list given in [6] and reproduced in 
Appendix 2. In effect, it uses only tost procedures 2a and 
2b but makes use of the knowledge about suspects returned 
by each of these procedures. It is seen that this informa- 
tion is sufficient to correct all pointer errors. Hence, 
if we decide to use the information about the suspects in 
diagnosis and correction, it is better to apply procedures 
2a and 2b before application of other procedures, so as to 
detect and correct any pointer error that is present. None 
of the other procedures is able to cover such a broad class 
of errors. 

4. 6 Correction of Data structures : 

4.6.1 Introduction s 

Having diagnosed an error to bo of a particular type, 
wo now consider some general remarks about tho correction of 
those errors. Taylor and Black have given a set of five 
general principles which a data structure and its correction 
algorithm should satisfy for correction [8], Data parti- 
tioning, avoiding unbounded foreign travel, coroutine traversal 
of data structures, using a fault dictionary and guessing in 
case of doubts are the five principles enunciated in it. It 
is to be noted that correction is a much more difficult pro- 
blem than detection or diagnosis and the development of a 
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correction procedure may not be straightforward. 

A general way to correct erroneous data structures 
for single errors, knowing the type and location of the 
error, is now presented. The assertions are again assumed 
to be represented by procedures which check for their 
validity. Within the procedure, there will bo a particular 
condition which will be checked to detect a violation of 
the assertion, and the identification of that condition 
is the key to correction. Mostly, these conditions are in 
the form of some equality. Its violation is an error. The 
correction procedure, therefore, attempts to set this 
equality right. The correction is achieved by changing the 
appropriate field of the culprit node to re— establish the 
equality. 

For example, if error 3a in a DLL was returned as 
true, it moans Id(Nl) and Id(N2) were not equal whore, N1 is 
suspect l 3a and N2 is suspect 2 3q . In combination with other 
procedures, it is possible to Identify the culprit among the 
suspects as that is what precisely constitutes diagnosis. 

Let us assume that the culprit node is suspec * 2 3a and the 
error type is diagnosed to be a change in Id-field. Then, all 
that is needed for correction is to make Id( culprit) = 

Id( other suspect). 
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4.6.2 Correction procedures j 

The Diagnosis-cum-correc tion procedures for the two 
data structures, r-SLL and DLL are now presented. 

(a) robust Singly Linked List t 

It should be noted that the * diagnostability * and 
correctability are not one, so correction of single errors 
may not always be possible. 

The procedure given below follows directly from the 
syndrome table for r-SLL and the detection procedures. 

If (error 2) 

then If (not error 3) 
then begin 

culprit := suspect 2 2 j 
Id( culprit):=Id( suspect 1 2 ) 

else 

culprit:=suspect 1 2 j 
' uncorrec table error* 
else 'undiagno sable error' 

(b) Doubly linked list (DLL) j 

The following routine may bo used for correction of 
single errors in a doubly linked list. The syndrome table is 
used in diagnosis and the detection procedures help in finding 
the equality condition which must be re-established for 


correction 



If (error 3a) and (not error 2a) 
then 

begin 

culprits=suspect 
Id( culprit):=Id( suspect 2^ a ) ) 
return 
end) 

If (error 3b) and (not error 2b) 
then begin 

culprit: =suspect l^-i 
Id(culprit) :=Id(suspect 2 3b ).) 
return 

end) 

Ir (error 2a) 

then If suspect i^^suspect 2^ 
then begin 

culprit: =suspect X 2a 9 
f ( culprit) :=suspcct a 2b 
return 

end) 

If (error 2b) 
then begin 

culprit: =suspect l 2b J 
f 2 ( culprit) :=suspect l 2a » 
return 


end) 
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If (error 4a) or (error 4b) 
then begin 

count (Npj):=K 
|k is the nodecountj 

end* 

Note the similarity between this procedure and the 
one presented by Taylor et al. in [6], which is also 
reproduced in Appendix 2. The above procedure, however, is 
derived entirely from the syndrome table and the detection 
procedures for DLL in a systematic manner. 

4.7 On-line Error Treatment i 

On-line error detection refers to detecting an error 
at the time when a particular portion of the data is being 
accessed. A similar notion applies to online error 
correction. We refer to the dotoction/diagnosis/correction 
problem as error treatment. Online error treatment is an 
advantage in cases where the nature of the transactions on 
the data is such that it is not possible to halt the system 
for purposes of error-checking. In a database environment, 
the need to take a ' be fore- imago ' is eliminated. Also, if 
the data is critical and the errors could not be tolerated, 
then, it is not advisable to do only a periodic run of the 

error detection routines, as the data between two such runs 

might have been in error, as also all the transactions done 

on such data. Under such circumstances, online error 
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treatment scores over the periodic treatment method. 

-line error detection (correction routines can be 
easily incorporated into any package of access mechanisms 
for a data structure, provided the structure can be described 
in terms of assertions such that none of them need an 
elaborate search through the node space of the instance 
to verify the assertion. 

If such on-line error treatment routines are available, 
they could bo included in the access mechanisms and the user 
need not be aware of it. Any access to data goes through 
these error treatment routines and an appropriate action is 
taken whenever an error is detected. If the error cannot be 
corrected on-lino, the user may be given appropriate message* 
If it can bo corrected, then it is done so, and the entire 
operations remain transparent to the user. Of course, all 
these, at the cost of efficiency of access, as every time the 
data has to go through the error treatment routines. 

Such on-line c-rror correction capability with complete 
transparency for single errors is possible in a doubly linked 
list (DLL) (with a stored count in the header and an Id-field 
in each node). Here, though procedures 4a and 4b require 
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elaborate traversing of the entire data structure instance, 
the count field, by itself does not contribute anything 
to the redundancy power of the structure and it is only the 
count that the procedures 4a and 4b check for. 
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5, SYNTHESIS OF ROBUST DATA STRUCTURES 

5. 1 Introduction : 

The synthesis of robust data structures is a difficult 
problem due to the following reasons s 

a) The lack of proper design criteria to be satisfied 
by the resultant structure 

b) The absence of design tools and methods to work with. 

Though the required criterion could be stated to bo 
detectability or correctability of some specified value, 
it is still a loose criterion. We shall later consider 
the number of changes required to maintain a valid instance 
with a different number of nodes (ch-diff) as a criterion [7]. 

5.2 Redundancy in a broader perspective ; 

Analysis and synthesis of robust data structures could 
be done under two seemingly different aspects. 

As far as the analysis is concerned, we could study the 
effect of additional redundant fields, or alternatively, given 
a fixed number of redundant fields, the effect of using them 
in various ways could bo studied. 

An example illustrating these two aspects is the 
follows [6] : 
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^ Add a 1 

; _ (Modify a • 

r-SLL r~ "7 7 3n 

i ! pointer j 

| DLL | pointer ^jniod(2)DLL 

field 

field ’• - 


Fig. 5.1 

The detectability of SLL goes from 1 to 2 by adding an 
additional field and resulting in the doubly linked list in 
the standard form. However, it is possible to increase the 
detectability to 3, not by adding an additional field, but 
by just using the available redundant fields in a better way. 
In a mod (2) DLL, the second pointer field points, not to 
the immediately proceeding node, but to the node preceding 
that. 

On the synthesis side, these two approaches would mean 
improving ’robustness' either by adding redundant fields or 
by a better use of available redundant fields. 

The second approach, i.o. efficient use of available 
fields, is considered now. 

5-3 The redundancy functional i 

The concept of redundancy functional (RF) was introduced 
in Section 2 (page 18) in connection with the *F' function 
in chained/ threaded binary trees. Every redundant field is 
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looked upon as containing an information which is the 
value dictated by the redundancy functional fox that field 
with that node as the argument. There may be different 
RFs associated with different redundant fields. 

An advantage in using RF is that the synthesis 
problem which we now concentrate upon, is simplified. All 
structures with a given amount of redundant fields per 
node are characterised by identical assertions in their 
model except that their RFs differ. We can obtain different 
data structures by changing the redundancy functional.. 

In a doubly linked list, the assertion 2, viz., 

f 2< N l> = N 2 =7* W = N 1 

can be restated as 

f 2 ( N 1 )<->F(N 1 ) 

where F is the redundancy functional. 

If wo. choose F as the ’predecessor function', we got 
the standard DLL and if we choose F to be 'the predecessor 
of predecessor function’ we got mod (2) DLL. 

In the case of threaded trees [4], the redundancy 
functionals would be the 'In-order successor’ (for the 
right link fields) and the ’ Inorder predecessor’ (for the 
left link fields) . For a chained tree [8], the RF is 
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’the next node in the Inorder sequence whose 

left (f^ is nil’, 

In some cases, the RF can not be described by a single 
statement. Procedural definitions of RF may be needed in 
such cases. (The inorder successor function in case of 
threaded tree is an example of this kind). 

5,4 rnQd(2) CT-tree : 

We use the idea of redundancy functional to modify the 
chained and threaded binary tree (CT-binary tree [6]). It 
will be on similar lines as the modification of a standard 
doubly linked list into a mod(2) DLL. 

5.4.1 Description of mod(2) CT-tree : 

The mod(2) CT-troo is a binary tree in which all the 
right-link fields with a logically nil value are replaced 
by a 'thread 1 and all the left link fields with a logically 
nil value are replaced by a 'chain'. (Tag bits are associa- 
ted with each pointer field to indicate whether the pointer 
is a normal pointer or a thread/chain. The pointer and the 
associated tag bit arc assumed to bo packed in a single 
1 field' • 

Threads and chains are formed for a mod(2) CT-tree 
in the following way. Informally, a thread from a node will 
point to a node which was pointed to by the succeeding thread 
(in the inorder sequence) for a CT-tree implementation of 
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the same data. Similarly, a chain from a node will point 
to a node which was pointed to by the succeeding chain 
in the corresponding CT-tree. (Refer to Fig. 5.2). 

The redundancy functionals for the mod (2) CT-tree 
can be stated as follow i 

Let bo the node under consideration. Then, for 
threads : 

It returns a value which is the pointer to a node Ng 
in the inorder successor of the node ^ in the tree 
which is the next node in the inorder sequence after 
N. with a logical nil value for its right field, 
and for chains t 

It returns a value which is the pointer to a node Ng 
such that Ng is the successor of successor of N^» 
whore ‘successor’ denotes that node which appears next 
in the inordor sequence with a logically null loft 
field value. 

5.4.2 Detectability of a mod (2) CT-tree : 

The detectability of a mod (2) CT-tree is 3. This is 
shown by concentrating on ch-diff, the minimum number of 
changes required to convert a valid instance of the data 
structure to another valid instance with a different number 
of nodes. This essentially involves attempted deletion of 

and has the least lower bound compared to 


some of the nodes 
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ch-same and ch-repl [7], So, one less than ch-diff is 
the detectability. 

The mod (2) CT-tree can be modelled using axiomatic 
assertions and can be analysed for its detectability. Given 
below is a different line of argument to show that its 
detectability is (at least) 3. 

It is meaningful to talk of an attempted deletion of only 
a subtree in a tree structure. The subtree 

'deleted' may be classified under one of the following s 

Case 1 The subtree has root with degree zero. (In 
effect, it has got just one leaf 
Case 1.1 The node A in the subtree is the leftson of its 
parent (Fig. 5.3a). 

In this case, there is one chain and one normal pointer 
coming 'into' the node A, which have to be changed. In 
addition, there always exists a thread of the type from B 
to C, which has to be modified to point to D. 

Case 1.2 The node A is the right son of its parent. 

In this case also, there is one chain and one normal 
pointer coming into the node which have to bo changed. 

In addition, a chain of the type from P to C has to 
change to point to D. It is to be noted again that three 
pointer changes are required. 
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Pig. 5.3(a) Illustrating case 1.1 
A is the node deleted 
±> is A's parent 

B is the none with a null right field 
and preceding A 

C is the node with a null right field 
and succeeding A 

3) is the inorder successor of C— ^ 

% »ThR€AX> 

<amm • C H A1 M 



Pig 5.3(h) Illustrating case 1.2 
A is the deleted node 


i is a's parent 

R is the node with a null left field 
and preceding A - 

B is the node with a null left field & preceding H 
0 is the none which has a null left field 
and succeeding a 

li is the node with a null left field & succeeding 0 
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•4 (a) Illustrating case 2.1 

A is the root of subtree deleted 
B is the node preceding G and -with a 
null right field m 

0 is the first leaf node in the 
subt ree 

D is the in order successor of C 


NORMAL POtNTER 
THREAD 


CHAIN 



Si g. 


5.4(b) Illustrating case 2,2 

A is the root of subtree deleted 
0 l ' ; 5 the leaf no-?.© in the subtree 

v » i« the nor. e croeeeiUig A an 1 having a 


f t field 
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Normal Po>pt rp 

— •— CHAIN 


/ Norms'* 

Pointer. 1 



fig. 5*5 Illustrating case 3 

A is the root of the subtree, R-j & R2 are the two sons of A 

C is th e 'first* leaf of subtree A 

D is the node with null left field and succeeding C 

E is the node with null left field and preceeding C 

B is the node with null left field ahd proceeding E 



57 


Case 2 The root is of degree 1. 

Case 2.1 The root has a left son (Fig* 5,4a). 

In this, case, in addition to a normal pointer and a 
chain, there will be one thread (like BD in Fig. 5,4a), coming 
into the subtree. This thread, in fact, will point to the 
inorder successor of the first loaf of the subtree. Those 
three pointers need to be changed when the subtree gets 
deleted. (The presence of an additional incoming chain is 
not guaranteed). 

Case 2.2 The root has a right son (Fig. 5.4b). 

In this case, in addition to a normal pointer and an 
incoming chain, which have to be changed, there will be 
another incoming chain (like BC in Fig. 5.4b), since there are 
atleast two nodes with logically null left fields in the 
subtree. (The presence of an incoming thread is not guaran- 
teed) observe that, again, atleast three pointer changes 
are required. 

Case 3 The root is of degree 2 (Fig. 5.5). 

An attempt to delete such a subtree will involve chang- 
ing atleast 2 incoming chains (which will be present 
anyway) and an incoming normal pointer, requiring atleast 
three changes. 
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If one of tho subtree of the root, and tho root Itself 
are deleted, and the parent of the root A is made to point 
to the root of the other subtree, then, it will involve 
changing one normal pointer say to J^2, atleast one incoming 
chain and either another incoming chain or an incoming thread, 
depending on whether tho right subtree or the left subtree- 
gets deleted along with the root. 

In addition, in all of the above cases, tho stored count 
has to change, requiring a minimum of 4 changes. Hence, 
the detectability is atleast 3. 

5, 5 Concluding remarks 

It is observed that, by varying tho redundancy functional, 
we can got variations of a data structure. This approach was 
used for synthesis using a fixed amount of redundancy. A 
storage structure, mod (2) CT-treo was developed, on tho 
lines of mod (2) DLL and CT-treo«and was shown to have a 
detectability of (atleast) throe. It is expected that a 
mod (k) Cl- tree can bo constructed on similar lines and the 
detectability will increase with increasing k (like mod (k) 

DLL) until the limiting factor (when ch-repl is exceeded by 
ch-diff) sets in. In case of chained and threaded trees it is 
expected that tho limiting detectability will be 4, because 
ch-repl Is 5, 
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6. CONCLUSION 

Protecting data by adding redundancy in the 
structure seems to be a good Idea, mainly because, it 
also aids in simplifying some user operations on the 
data. Such techniques can be used wherever large and 
critical data are being stored, like data bases. Though 
wo have considered only pointer- type structures, it is 
justified by tho wide use of such structures in many 
applications. 

The detection and correction procedures presented 
in Section 4 are certainly not tho most efficient. Never- 
theless, they were derived in a systematic manner from the 
descriptions of data structures and this method will be 
useful particularly when the structure is complex. 

It is felt that most of tho problems of efficient use 
of available redundant fields can be dealt with using tho 
redundancy functionals. The idea which was used to develop 
mod (2) CT-tree can be extended to other structures also to 
make them robust. Finding a proper design criterion to be 
satisfied by the redundancy functional is another direction 
in which this work can bo extended. 

The detectability and correctability presented here are 
worst case values. As per the results of simulation studies 
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done by Taylor et al* [6], the data structures are found 
to behave much better than the predicted values, mainly 
because the chances of the worst combination of errors 
occurring is very small. This gap between theory and 
practice can be bridged if the probabilities of various 
types of errors occurring are also considered. 

In general, the performance of the system goes down 
due to the presence of redundancy and more complex update 
routines. Thus, there is a trade-off between reliability and 
efficiency. 
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APPENDIX 1 

Distinguishing between a forward pointer change 
to a local node and a back pointer change to 
a local node in DLL 


In these cases, the following are the values of 
error flags ; 

Error 2a = True 
Error2b ~ True 
Error3a = False 
Error3b = False 

We do not resort to procedure 4a or 4b for this 
diagno sis . 

Each of the procedures 2a, 2b, 3a and 3b (given in 
Appendix 3) return two suspects, suspect 1 and suspect 2. 
The following procedure will distinguish between the two 
types of errors in question. 





/ 


A 



N 


X 1 JiC,.. 
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If suspect l_ 2 a = suspect 2 2b 

then error type forward pointer changing to a local 

node* 

else If suspect l 2b = suspect 2 2a 

then err or type := ’back pointer change to local node* 
else 'multiple errors’) 
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APPENDIX 2 

Reproduction of a linear list correction procedure 

from [6] 

The following procedures detect and correct all 
single errors in a DLL. 

Procedure LIST-CORR (H,N)j 
begin 

pointer H, Integer N, Pointer P^ 

Pointer Prev-P, Integer Jj 

/*H is the header of the structure, N is expected 

count */ 

J — 0* 

Prev-P Hj 
P Forward (H).j 
While (P £ H) do 
begin 

If (Back(P)s Prev-P) and (Id(P) correct) 
then begin 

Prcv-P P j 
P -^"Forward (?) 

end 

else 

begin 
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| else 

begin \ 

BACKSCAN (H,P,Prev~P ) $ 
return 

end 

ond\ 

If (Back(H)^Prev-P) or (Id(H) incorrect) 
then begin 

BACKSCAN ( H , P , Pr ev-P) 
return 
end* 

If(J^N) then N<— J 

end* 

Procedure BACKSCAN (H,P,Prev-P)> 
begin 

Pointer H, Pointer P, Pointer Prev-P, 

Pointer Q, Pointer Prev-Q* 

Prev-Q — H$ 

Q Back (H).j 
repeat 
begin 

If ( Forward(Q )=Prev-Q) and( Id (Q) correct) 
then begin 

Prev-Q < — - Q* 

Q ^ — Back( Q) 
end 
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.^repeat 

begin 

If (Forward(Q)=Prev-Q)and(Id(Q) correct) 
then begin 

Prev-Q-^-— Qj 
Q Back(Q) 

end] 
el se 

begin 

L ~RE PAIR ( P , Pr e v-P , Q » Pr e v-Q ) j 
return 

end 

end 


end* 

Procedure L-REPAIR(P 1 Prov-P,Q,?rev=Q)j 
begin 

Pointer ?, pointer Prev-P, pointer Q, Pointer Prev-Q* 
If (p=Q and Id(p) irwcorrect) 
then Id(P) - correct i.d. 
else If (P=Prev-Q) 

then Back (Prev-Q) Prev-P 
else If(Prev-F=Q) 

then forward (Prev-P) <7- Prev-Q 
else 'multiple error’ 
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APPENDIX 3 

Given below are the procedural equivalents of the 
assertions used to describe a DLL in Section 2. 

Assertion 2 : 

These assertions check whether the forward and back 
pointer of ’adjacent* nodes are properly formed. In 
procedure 2a, checking assertion 2a, the traversal is done 
using forward pointers, while a check on the previous node 
encountered is made. Procedure 2b uses traversal via back 
pointer (f 2 ). Either of the procedures terminate when an 
error is detected or if the header is reached. 

Procedure 2a (N^: node)* 

Global Var Error 2a s Boolean* suspect 1^, 

suspect 2 2a s Node* 

Var Node| 

Begin 

N1;=^ h * Error 2a:=false* suspect l 2a :=nilj 

suspect 22 a s=nil* 

repeat 

N2:=f 1 (N 1 ) * 

If (f 2 (N 2 )*N 1 ) 
then Nls=N2 
else error2a:=true 
until (N2=N h ) or (error 2a)* 

If error 2a then 



£ until (N2-N^) or (error2a)j 


If 


orrox2a then j 
begin 

suspect l 2a 
suspect 2 2a 


-Nil 

=N2 


end 


end* 

Procedure 2b(N H :Node)| 

Global Var Error2b: Boolean* 

suspect l 2b » suspect 2 2b iNode 

Var 

Nl f N2:=Node> 

Begin 

Nl:=r^j error2b:=falsej 

suspect l 2b i=nil| suspect 2 2b :=nilj 

repeat 

N2s=f 2 (Nl)| 

If (f^N^sNi) 
then Nl:=N2 
else error2b:=true 
until (N2=Npj) or (err or 2b)* 

If error2b 
then begin 

suspect l 2 b :=Nlj 
suspect 22 ^ 1^2 


end 
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Assertion 3 i 

The following procedures check for the validity of 
assertions 3a and 3b. It is checked whether adjacent nodes 
have same Id— values or not. Procedure 3a uses traversal 
along forward pointer and procedure 3b uses the back pri 
pointer for traversal. A count of the number of nodes is 
kept in both cases to ensure termination of the procedure 
within a finite time. 


Procedure 3a(N^) :Node) * 

Global Var error3a: Boolean* 

suspect lg a > suspect 2^: Node* 

Var 

Nl,N2s Node* m, nodecount: Integer* 
^checks for validity of assertion 3a of DLL 
Begin 


N1:=NH* error 3a:=false$ suspect l 3a :=nilj 
suspect 2 3a :=nil* nodecount: =0* 


m:=count (N^)j 


repeat 

N2:=f^(N^) jNodecount:==nodecount+l* 
If ( Id(Nl)=Id(N2) ) 


then N1:=N2 
else error3a:=true 



69 


^ then Nl:=N2 
else error 3a :=true^ 

until (N2=Np.) or (error 3a) or (nodecount 3^- m+l)? 
If error 3a then 

begin suspect l 3a :=Nl.* 
suspect 2 3a J=N2.j 

end 

end) 

Procedure 3b(N^sNode ).j 

Global Var error 3bs Boolean? suspect l 3b i 

suspect 2 3b :Node? 

Var Nl,N2jNodej m,nodecountj Integer? 

Begin 

Nl:=Npjj error 3b:=false? suspect l 3b s=nil? 
suspect 2 3b : =nil?nodecount:=Ojm:=count(N^) j 
repeat 

N2:=f 2 (Nl) ?nodecounts=nodecount+l? 

If ( Id(N2)=Id(Nl) ) 
then Nli=N2 
else error3b:=true 

until(N2=M^) or (error3b) or (nodecount ^ m+l) ? 
If error3b then 
begin 

A 

suspect l 3b :Nl? 
suspect 2 3b i=N2 
end? 


end? 
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Assertion 4 : 

The following procedures check for the validity of 
assertions 4a and 4b. Traversal using one of the two 
pointer fields is done over the entire structure and a count 
of the nodes encountered is compared with the stored count 
for any mismatch. 

Procedure 4a (N^s Node)) 

Global Var Error 4a: Boolean) 

Var Nl, N2: Node jm, nodecount; Integer j 

^checks whether the stored count matches with the 

number of nodes J- 

Begin 

Nl:=N^j nodecount: =0) error4a:=false) 

m;=count(N H ) ) 

repeat 

N2:=sf 1 (Nl)j nodecount: =nodecount +1> 

If (N2=N U ) then error4a:=nodecountj^m+l 

ll 

until (nodecount ^ m+l)or(error4a) ) 

If (node count ^m+l) then error 4a: =3^% 

end.) 

Procedure 4b (N^: Mode) ) 

Global Var Error4a:Boolean) 

Var Nl,N2:Modejm, nodecount: Integer) 

) Check actual number of nodes, using traversal via f 2 J 
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Begin 

N1j=N h i nodecount s=0, error4b;=false* 

m;=count (N^)j 

repeat 

M2; =f2(Nl) $ nodecount;=nodecount+lj 
If (N2r=N^) then error4b;=nodecountj6m+l, 
until (node count ^ m+1) or (err or 4b)* 

If ( nodecount ^ m+1) then error4b:=M2^Npj 


end * 
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